<template><div><h2 id="版本说明" tabindex="-1"><a class="header-anchor" href="#版本说明"><span>版本说明</span></a></h2>
<p>Yii 中文文档 /</p>
<h2 id="yii版本控制" tabindex="-1"><a class="header-anchor" href="#yii版本控制"><span>Yii版本控制</span></a></h2>
<p>本文总结了Yii的版本控制策略，我们当前的版本控制策略是 <a href="http://semver.org/lang/zh-CN/" title="语义化版本" target="_blank" rel="noopener noreferrer">语义化版本</a> 的一种变体。</p>
<p>在核心开发团队中，我们已经多次强调了保持 2.0.x 发行包向下兼容的重要性。但是，理想很丰满，现实很骨感。关于BC是什么，请参阅 <a href="https://github.com/yiisoft/yii2/blob/master/docs/internals/bc.md" target="_blank" rel="noopener noreferrer">向下兼容</a> 文档的详细描述。</p>
<p>总之，我们的 Yii 2 版本控制策略如下：</p>
<h2 id="版本号" tabindex="-1"><a class="header-anchor" href="#版本号"><span>版本号</span></a></h2>
<p>版本号的格式为 <code v-pre>2.x.y.z</code>，对于 <code v-pre>z</code> 为 <code v-pre>0</code> 的版本，可以跳过<code v-pre>z</code>。</p>
<p>这里没有讨论未知的 Yii 3，因为我们希望它像 2.0 而不是 1.0。我们预计这种情况每3到5年才会发生一次，这取决于外部技术的进步（比如 PHP 从 5.0 升级到 5.4）。</p>
<h3 id="_2-x-0-主版本" tabindex="-1"><a class="header-anchor" href="#_2-x-0-主版本"><span><code v-pre>2.X.0</code>: 主版本</span></a></h3>
<p>向后兼容性破坏版本，其中包含可能破坏 BC 的主要特性和更改。从早期版本升级可能不是一件小事，但一个完整的升级指南将可用。</p>
<ul>
<li>主要包含新特性和bug修复</li>
<li>包含从补丁发布中合并的小功能和 bug 修复</li>
<li>可能包含破坏 BC 的更改，这些更改记录在 <code v-pre>UPGRADE-2.X.md</code> 的文件中</li>
<li>发布周期约为 12 个月或更长时间</li>
<li>需要预发行版： <code v-pre>2.X.0-alpha</code>, <code v-pre>2.X.0-beta</code>, <code v-pre>2.X.0-rc</code></li>
<li>需要大量的新闻发布和营销工作</li>
</ul>
<h3 id="_2-x-y-次要版本" tabindex="-1"><a class="header-anchor" href="#_2-x-y-次要版本"><span><code v-pre>2.x.Y</code>: 次要版本</span></a></h3>
<p>次要版本，主要与 BC 兼容。理想情况下，我们希望它们只包含不影响向后兼容性的更改。然而，无法总是保持所有内容 100% 与 BC 兼容, 因此，更新日志会记录在 <code v-pre>UPGRADE.md</code> 中。实际上，自 2.0.x 版本发布频率越来越高以来，我们也在添加一些小功能，以便用户能更早地使用它们。</p>
<ul>
<li>主要包含 bug 修复和增强（#enh）</li>
<li>应该基本上是向后兼容的，以确保无需担心升级。只有少数例外是允许的，这些例外在 <code v-pre>UPGRADE.md</code> 中有记录</li>
<li>发布周期约为 1 - 2 个月</li>
<li>不需要预发行版（ alpha，beta，RC ）</li>
<li>应该经常合并回主分支（至少每周手动一次）</li>
<li>伴随着新闻公告，项目的官网将会更新它</li>
</ul>
<h3 id="_2-x-y-z-补丁版本" tabindex="-1"><a class="header-anchor" href="#_2-x-y-z-补丁版本"><span><code v-pre>2.x.y.Z</code>: 补丁版本</span></a></h3>
<p>补丁版本，应该是 100% 与 BC 兼容的，只包含错误修复。没有新闻公告或项目站点更新（除非包含重大/安全问题修复）。<br>
发布过程大部分是无感的。</p>
<ul>
<li>只包含bug修复，不包含特性</li>
<li>必须100%向后兼容，以确保无需担心升级。唯一的例外是安全问题可能需要破坏 BC</li>
<li>发布周期大约是 1 - 2 周</li>
<li>不需要预发行版（ alpha，beta，RC ）</li>
<li>应该在发布时合并回主分</li>
</ul>
<h2 id="分支策略" tabindex="-1"><a class="header-anchor" href="#分支策略"><span>分支策略</span></a></h2>
<ul>
<li>
<p><code v-pre>master</code> 分支是当前稳定的主版本及 <code v-pre>2.0.x</code> 系列版本的开发分支</p>
</li>
<li>
<p>每个新的主要版本将在一个以版本号命名的分支上开发，例如 <code v-pre>2.1</code>。</p>
</li>
<li>
<p>一旦一个新的主要发行 <code v-pre>2.n</code> 准备好后，在 <code v-pre>master</code> 下，创建一个名为 <code v-pre>2.(n-1).x</code> 的维护分支。<br>
例如，如果 <code v-pre>2.1.0</code> 版本是稳定发布的，那么就会创建一个 <code v-pre>2.0</code> 分支，并且现在会在 <code v-pre>master</code> 上开发（cmp. <a href="https://getcomposer.org/doc/02-libraries.md#branches" target="_blank" rel="noopener noreferrer">composer 分支命名模式</a>）</p>
</li>
<li>
<p>创建 tags <code v-pre>2.x.y.z</code> 和 <code v-pre>2.x.y</code> 分支，去标记补丁发布，当 <code v-pre>2.x.y.0</code> 发布时，<code v-pre>0</code> 将被忽略。</p>
</li>
<li>
<p>在 <code v-pre>2.n.x</code> 维护分支上的更改，将不断地合并回 <code v-pre>master</code></p>
</li>
</ul>
<p>下图展示了在一段时间内更改提交历史记录的分支：</p>
<p><img src="https://cdn.learnku.com/uploads/images/202201/26/93088/YPdiComPTx.png!large" alt="分支策略"></p>
<h2 id="发行" tabindex="-1"><a class="header-anchor" href="#发行"><span>发行</span></a></h2>
<p>框架和官方扩展项目相互独立发布，即框架和扩展之间的版本号不匹配。应用模板总是和框架一起发布的。</p>
<p>上面描述的发布周期只适用于核心框架。扩展是按需发布的。<br>
扩展很可能在很长一段时间内都没有新版本，因为它没有得到任何 bug 修复或增强。</p>
<blockquote>
<p>💖喜欢本文档的，欢迎点赞、收藏、留言或转发，谢谢支持！<br>
作者邮箱：zhuzixian520@126.com，github地址：<a href="https://github.com/zhuzixian520" target="_blank" rel="noopener noreferrer">github.com/zhuzixian520</a></p>
</blockquote>
</div></template>


